Creating Case Definitions
A case definition is a JSON document conforming to the WKS Case Configuration Standard. You can author one through the Case Builder UI or by importing JSON. This guide covers the fields you set and the order that makes sense.
1. Open the Case Builder
Log in to the portal and go to Management → Case Definitions, then create a new definition (or edit an existing one). The builder is a tabbed editor; a JSON tab shows the live definition and validates it against the Standard as you work.
2. Set the basics
Provide the core identity fields (see the field reference):
id— a stable slug, unique across case types.name— the human-readable name.formKey— the key of the Form that captures and displays case data.deployed— set totrueto make the type available to end users.stagesLifecycleProcessKey— the BPMN process key, if you run with a workflow engine; leave empty when running engine-less.
3. Define the stages
Add the ordered stages the case moves through. Each stage needs an id, a zero-based index, and a name. The name is what transitions reference.
4. Wire up event listeners
Add event listeners (caseHooks) to drive automation — for example, when task create-ticket completes, move to stage Issue Investigation. Remember that stage and queue actions reference targets by name.
5. The Kanban board
The kanban board for a case type is derived automatically from its stages — each stage becomes a column, in index order. There is nothing to configure here (the old kanbanConfig field was removed in Standard 2.0). Per-card presentation is being moved into a separate board-config artifact.
6. Validate and save
Open the JSON tab to confirm the definition conforms to the Standard (the tab flags the number of issues if any). Validation does not block saving, but a conforming definition is one that will behave predictably. Save to persist via the configuration API.
You can also export and re-import definitions as JSON to move a configured case type between environments.